Date: Thu, 30 Sep 93 04:30:12 PDT 

From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu> 
Errors-To: Ham-Digital-Errors@UCSD.Edu 

Reply-To: Ham-Digital@UCSD.Edu 

Precedence: Bulk 

Subject: Ham-Digital Digest V93 #59 

To: Ham-Digital 


Ham-Digital Digest Thu, 30 Sep 93 Volume 93 : Issue 59 


Today's Topics: 
<none> 
Any experience from delta modulation?? 
FTP source for JNOS 1.08 
MULTICOMM V3.0 (2 msgs) 
News via FM Subcarriers/receiving data broadcasts (2 msgs) 
Public access Packet question 
simtel20 going away for good 
Soundblaster (tm) for multi-mode digital communications ?? 
Telnet-2m Gateways? 
test 


Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu> 
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: 30 Sep 93 05:31:01 GMT 

From: ogicse!uwm.edu!spool.mu.edu!wupost!csus.edu!netcom.com! 
fmitch@network.ucsd.edu 

Subject: <none> 

To: ham-digital@ucsd.edu 


Nels Harvey (NHARQQOO@MUSIC.LIB.MATC.EDU) wrote: 


: In the Southeastern Wisconsin area, we are trying to upgrade the 

: backbone from 4800 baud to 9600 baud. My problem is, a Kantronics data 
: engine, an MFJ 1274, an MFJ 9600 baud modem, a deviation of 3 KHz. all 
: at about 200 ft. doesn't work! 4800 baud works fine! 


: We are using Icom 3200's as part of the 9600 baud network. They talk 
: to each other! 


: I'm open to any suggestions to get this Kilobuck project resolved. We 
: don't have a path problem, this isn't working on the bench! Is there 
: something I've overlooked? 


: Has anyone had problems with the Data Engine? 


Hi Nels. I am using the Data Engine with a Alinco DR-1200 on the 
DX Cluster backbone here in Mobile and it works great. At last 
count, we had 19 Data Engines (most running BPQ code) on the 
Gulf Net Backbone. They work great. I suggest you get a good 
service monitor and look at your rf. The best service monitor 
we have found to use is an IFR1200S. You can tell instantly 

by the "eye" pattern on the sm what the source of your problem 
is. You can see if you have too much phase jitter (multiple 
squiggly lines), AMing (multiple top and bottom lines) or just 
plain distortion. The service monitor is the *_ONLY_* way to 
get your 9600 going! I speak from experience! The expert 

on Data Engines and 9600 baud is Jim Moore, WU3V in Lafayette, 
LA., 318-893-9455 home, 318-231-6141 work. Good luck! 


Mitch, WA4OSR 


fmitch@netcom.com 
Felton Mitchell, WA40SR in Mobile, Alabama USA 
co-sysop for W4IAX bbs running fbb ... sysop for WA4OSR DxXCluster in Mobile.. 


Date: Wed, 29 Sep 1993 17:15:22 GMT 

From: news.service.uci.edu!ttinews!calvin.tti.com!cole@network.ucsd.edu 
Subject: Any experience from delta modulation?? 

To: ham-digital@ucsd.edu 


In article <1993Sep28.132547 .13088@ke4zv.atl.ga.us> gary@ke4zv.atl.ga.us (Gary 
Coffman) writes: 


>You may want FEC, but resends generally are not satisfactory. You have 
>to reproduce a continous speech stream, and resends will be unacceptable 
>at speeds we can reasonably muster. What you do instead is simply output 
>the bad bits as a brief noise burst, or output a 50% level for bits you 
>know are bad. IE if you're encoding with 8 bits, uncorrectable bad bytes 
>are output as 128. Speech is redundant, and there is context to help even 
>further, so brief strings of uncorrectable bit errors only add a bit of 
>static to the signal. 


There are many ways to deal with a known bad speech sample, but 
outputting a "50% level" isn't one of them. The simplest is to 
repeat the previous sample. A better, but not quite as simple, 
method is to interpolate between the preceding and following samples. 
An evnn better way is to run a short predictor at the decoder. 


The original poster was talking about delta modulation, so we're 
not talking about bad output speech samples anyway, but rather 
about bad quantized deltas. The effects of a single error can be 
felt for a long time. 


In a packet system the lower-level protocols probably aren't going 
to pass up bad packets anyway. 


The first packet voice experiments I know of were done in 1974 
over what was then called the Arpanet. Interestingly enough, delta 
modulation was used for those experiments, namely 8 kilobit/sec CVSD. 


Randy Cole 
KN6W 
cole@soldev.tti.com 


Date: Wed, 29 Sep 93 01:17:19 -0400 

From: psinntp!wlnntp.psi.com!usenet@uunet.uu.net 
Subject: FTP source for JNOS 1.08 

To: ham-digital@ucsd.edu 


>DATE: Tue, 21 Sep 1993 14:34:02 -0600 

>FROM: Burt Kaufman <Burt.Kaufman@f40.n382.z1.fidonet.org> 

> 

>Can anybody point me to a site that has JNOS version 1.08c available for 
>anonymous FTP? 


Go right to the "source" -- the host is wg7j.ece.orst.edu -- and I 
believe the directory names are the version numbers. You'll have to 
check that... 


>If possible, simple instructions on how to initiate the transfer would 
>be helpful as well. 


Try the "man £tp" command if you are on a Unix system to read the FTP 
manual pages. 


ftp wg7j.ece.orst.edu 
will open an FTP connection to the specified host 


you can issue a "?" to see the list of commands or "?,<command>" with 
no quotes or brackets to see a one-line description of <command>. 

Use "cd" to change directories on the remote, "1s" or "dir" 
to get directory listings. 


This one is a MUST for retrieving anything but simple text files -- 
"binary" which sets binary mode (ascii is the default) and must be used 
for any compressed files, including .zip files. 


To actually retrieve the file, use the "get" command: 

get xyz.zip 

assuming you have already set the curent directory. Or, use the full 
path. 


Then use exit or quit (I forget which) to close the connection and 
leave FTP. Happy hunting! 


-Seth 


Date: Thu, 30 Sep 1993 03:07:38 GMT 

From: munnari.oz.au!bunyip.cc.uq.oz.au!un! gcO34@uunet.uu.net 
Subject: MULTICOMM V3.0 

To: ham-digital@ucsd.edu 


Date: Thu, 30 Sep 1993 00:13:42 GMT 

From: munnari.oz.au!bunyip.cc.uq.oz.au!un! gcO34@network.ucsd.edu 
Subject: MULTICOMM V3.0 

To: ham-digital@ucsd.edu 


Date: Wed, 29 Sep 1993 04:35:41 GMT 

From: agate!spool.mu.edu!umn.edu!csus.edu!netcom.com!kors@ames.arpa 
Subject: News via FM Subcarriers/receiving data broadcasts 

To: ham-digital@ucsd.edu 


: Anyone out there have any experience getting news & stock info via FM 
: subcarrier? 


: Most of the wire services are now sending stories out this way, as are lots 
: of smaller, specialized information services. 


: Some of this info appears to be encrypted; anyone know anything about 
: that? What are the best receivers & software packages? 


I've tried a lot of systems, most of which are usless for serious stock 

trading. The closest that is a real tool is from Data Broadcasting Cor[poration 

of San Mateo, CA. I suggest you contact them for detailed information. I have 

my SCA receiver for sale are a very good price if you think you'd like to 

work with them.. The coding they use is impossible to hack (never say never), 

but good luck. There are simplerr way to beat their system, but of course are all 
illegal. 


kors@netcom.com 


Date: 29 Sep 93 17:41:04 GMT 

From: swrinde!cs.utexas.edu!uwm.edu!biosci! joes! shibumi@network.ucsd.edu 
Subject: News via FM Subcarriers/receiving data broadcasts 

To: ham-digital@ucsd.edu 


jubois@netcom.com (Jeff Ubois) writes: 
>Some of this info appears to be encrypted; anyone know anything about 
>that? What are the best receivers & software packages? 


The ones sold by the service providers -- this information is not intended 
for general public consumption (except by subscription) and is protected by 
ECPA. 


| Kenton A. Hoover | 
| P.O. Box 882643 +1 415 957 3614 | 
| San Francisco, Kalifornia 94188-2643 shibumi@joes.garage.com | 


| "Answer the door! It is Phil, who brings with him the constant promise of | 
| pleasure and fulfillment in its most primitive form." 


Date: Wed, 29 Sep 1993 13:26:14 GMT 
From: mulvey!rich@uunet.uu.net 
Subject: Public access Packet question 
To: ham-digital@ucsd.edu 


mont@ibmmail.COM wrote: 


I have a Unix box connected to my TNC-2M rig. I would like to set 
up a public-access land-line BBS for Amateurs that will allow them to dial up 
my machine, and would then put them into a shell. This shell will 
automatically set their call-signs, etc, and not allow them to 
change it. However, they will still be able to connect to our local 
backbone system, and from there, connect to wherever they want. I'll 
keep a log of activity on the system, so if something goes wrong, I'll 
know who to blame. :-) I'd like to give some local people who have 
computers but no TNCs a taste of what packet can give them. 


Since I will only allow verified Amateurs on the system, I look at 
that as giving them permission to be control-ops for my equipment. 


VV VV VV VV VV VV VV 


Does this sound feasible? 


: This is almost exactly what we are doing where I work. We have a 
company sponsure ham club with a tnc2, 2 com ports, and an AT. One 

: com port is connected to a data switch and is accessible from any 
phone throughout the site that has the data (rs232) option enable. 


: I wrote some software for the club that listens for a connect request, 
prompts users for login info (userid & password), and if valid, then 
pipes all i/o from com1 to a tnc2 on com2. This allows all valid 

: members of the club access to the packet station right from their 

: desks. The software also supports looking up callsigns, and changing 

: the packet radio's frequency (another board connected to the parallel 
port controls the radio's freq). 


: I think the FCC wording for this kind of setup is "remotely controlled" 
: where the control operator is controlling the station from a remote 

: location. The remotely controlled station could be controlled via 

: radio link, and/or telephone lines. 


: As far as forcing the packet callsign to be a certain callsign based 

: on their login is not really needed. The amatuer acting as the control 
: operator is still responsible for iding the station. However, it is 

: still useful, because then the control operator doesn't have to remember 
: to set it themself (it's easy to forget). 


: Since you would probably share in the blame if someone illegally used 
: your station you will need to be careful how you give access to users. 
: You might want to have them preregister by sending you a copy of their 
: license, or reguire that their call be found in the latest callbook, 

: or something like that. 


Well, my plan is to allow access only to those people who have sent 
me license copies and who I can reach by phone ( or repeater ;-) While 
I feel enough altruism to allow people to use my equipment, it isn't 


strong enough that I'm willing to risk getting a NAL from Unc Sam, so 
it's not going to be open to every Amateur in the area. 


My rational for providing them with a shell that automatically sets up 
their callsign and connects them to the backbone is to eliminate the 
problem you noted about forgetting to set MYCALL, and also to simplify 
matters for the neophytes that I'm targeting. 


- Rich 
Rich Mulvey Amateur Radio: N2VDS Rochester, NY 
rich@mulvey.com "Ignorance should be painful." 


Date: 29 Sep 93 14:28:31 GMT 

From: news-mail-gateway@ucsd.edu 
Subject: simtel20 going away for good 
To: ham-digital@ucsd.edu 


Greetings All, 

I have known for some time that the Simtel20 was going to be trashed on 
the 30 of September. I have seen no word of it on this thread. I signed on 
this morning and got this message: 


WSMR-SIMTEL20.ARMY.MIL, PANDA TOPS-20 Monitor 7.1(21733) -4 
The system will go down 30-Sep-93 16:00:00 until 1-Jan-2000 00:00:00 
for Final shutdown of SIMTEL20 


| Unauthorized access to this computer system is prohibited and is | 
| subject to criminal and civil penalties (18 USC 1030 and 18 USC 2701). | 


Please send all SIMTEL20 problem reports via email to ACTION. 


xxx Due to funding constraints, realignment of mission xxx 


xxx functions, and Department of Army downsizing; KKK 
KKK SIMTEL20 will cease operations !!! KKK 
KK 30 SEPTEMBER 1993 - 1600 HOURS MDT KK 
xxx There are two days more of SIMTEL20 operations! *KK 
KK KK 


If there is anything you want to download from the massive MS-DOS 
archives, the next day or so is all you have. 


I still don't know if this newsgroup will be supported by the other 
system at White Sands Missile Range. 

I've enjoyed the high level of technicial discussions and hope that the 
other system will get this newsgroup in the future. 

My old address: lspringsteen@wsmr-simtel20.army.mil 

My new address: lsprings@wsmr-enh15.army.mil 

Packet: WB8LBZ @ K5WPH.NM.USA.NA 


73 for now, Larry 


Date: Wed, 29 Sep 1993 18:46:26 GMT 

From: news.service.uci.edu!paris.ics.uci.edu!csulb.edu!library.ucla.edu!agate! 
doc.ic.ac.uk!uknet! bnr.co.uk!bnrgate!nmerh207! corpgate!nrtpa038! brtph560!b4pphi3e! 
cnc23a@network.ucsd.edu 

Subject: Soundblaster (tm) for multi-mode digital communications ?? 

To: ham-digital@ucsd.edu 


I recently saw an advertisement in QST of a software program that will 

use the Soundblaster(tm) for SSTV decoding. I know of a public domain program 
that uses the Soundblaster(tm) for DTMF decode. The VOICEBLASTER (tm) product 
will do voice recognition. 


This leads to a simple question : "Can the Soundblaster (tm) be programmed to 
do all the 1200, 2400, 9600, afsk, psk, etc. TNC work, (Color) SSTV, WEFAX, 
RTTY, CW, AMTOR, FAX, PACTOR, CCTSS, DIMF, etc. etc. work that a multi-mode 
digital controller does ?" I realize there would need to be some sort of I0 
board/port to to tramsmitter keying, but is it possible ? 


Ken M. Edwards, PE Bell Northern Research, Research Triangle Park, NC 
(919) 481-8476 email: cnc23a@bnr.ca Ham: N4ZBB 


All opinions are my own and do not necessarily reflect the views of 
my employer or co-workers, family, friends, congress, or president. 


Let this be the day... 

when you stop just thinking about your dreams, 

and you start doing something to make them happen! 
Let this be the day... 

you give your best, 

believe that you can make a difference in the world, 


because it's true! 
Let this be the day... 
when you can honestly say 
you've lived life to the fullest. 
Linda Lee Elrod 


Date: Wed, 29 Sep 1993 15:48:13 GMT 

From: news.cerf.net! kaiwan.com! topolski@network.ucsd.edu 
Subject: Telnet-2m Gateways? 

To: ham-digital@ucsd.edu 


Does anyone have a current list of the available telnet->packet gateways 
available? 


Robert M. Topolski <topolski@kaiwan.com> 


Date: 29 Sep 93 16:11:51 GMT 
From: news-mail-gateway@ucsd.edu 
Subject: test 

To: ham-digital@ucsd.edu 


‘lo all! 

Sorry for test... but I want to know if I'm posting 100% or not 
before send anything... :))) 

ROD. 


Date: 29 Sep 1993 03:37:45 GMT 

From: dog.ee.lbl.gov!agate!howland.reston.ans.net!sol.ctr.columbia.edu! 
news .unomaha. edu! crcnis1.unl.edu!unlinfo2!mcduffie@network.ucsd.edu 

To: ham-digital@ucsd.edu 


References <1993Sep27 .141808 .13231@mnemosyne.cs.du.edu>, 
<1993Sep27 .175914.10643@news .mentorg.com>, 

<1993Sep28 .190214 .9045@mnemosyne.cs.du.edu> 

Subject : Re: Responsibility for BBS messages 


lkollar@nyx.cs.du.edu (Larry Kollar) writes: 


>In another message, Gary McDuffie compares forging a call on packet to 
>using a bogus call on a repeater. However, repeaters are not assumed 
>to be running unattended (like most packet BBSes/forwarding nodes). 
>[Or are they? Oh well, I'm sure I'll hear about it if I'm wrong. :-)] 


You must live in the big city. Can you say AUTOMATIC CONTROL? I have 
no idea what the numbers are, but I would bet that over 90% of the 
repeaters in the country are run under automatic control. Under 
automatic control, a repeater is assumed to be used properly until 
evidence to the contrary is found. At that time, steps are taken to 
keep the event from happening again. There are relatively few 
repeaters that have control ops sitting on the edge of their seats, 
waiting for someone to utter the wrong words. That's the way the BBS 
network should be. Let it run. When an abuser is found, get rid of 
him. In the meantime, things flow normally and expeditiously. 


>Assuming I'm right about repeaters -- the FCC figures we put up with control 
>operators on repeaters; why shouldn't we put up with the equivalent on packet? 


Why should we be bothered? 


>Larry Kollar, KC4WZK 
How about this aside: 


This is off the subject slightly, but it parallels the subject in the 
first paragraph. In some areas, it is considered okay to put someone 
else's call in your tnc to accomplish a specific task. This may seem 
absolutely taboo to some, but stop and think about it for a minute. If 
you satisfy the requirement of identification with a UI beacon frame 
but have a different callsign in the MYCALL parm, you can check into 
the local board with whatever callsign you choose. If you originate a 
message while you are on that board, it will show it as coming from 
the callsign in your tnc, not the one you are beaconing as an ID. You 
think this can't be done? Have you ever heard of an alias? What if my 
callsign is AGON and my alias is WBOKKM? Do you know of a rule that 
says your alias can't be something that resembles a callsign? Shall we 
get deeper into discussions of callsign legality with the nodes in the 
west? How about RENO or SFO? There are many more. 


Things that make you want to say hmmm..... 


Gary - AGON 


Date: 29 Sep 93 06:50:57 GMT 

From: munnari.oz.au!sol.ccs.deakin.edu.au!news.cs.uow.edu.au!mippet.ci.com.au! 
eram! dave@network.ucsd.edu 

To: ham-digital@ucsd.edu 


References <748474616snx@llondel.demon.co.uk>, <281nbg$h7j@crcnis1.unl.edu>, 
<CE1506.142r@austin.ibm.com>m 
Subject : Re: Responsibility for BBS messages 


In article <CE1506.142r@austin.ibm.com>, 
miltonm@austin.ibm.com (Milton D. Miller II) writes: 


| Evidently, the FCC thinks it 
| is too easy to forge a message in someone elses name/call. 


It's as trivial as "MYCALL xxxxxx" on your TNC; a spate of which is 
happening in Sydney right at this moment (and no, nothing to do with 
the Olympics; it's targeted against certain individuals such as myself). 


Anyone tried packet DF-ing? 


Dave Horsfall (VK2KFU) VK2KFU @ VK2RWI.NSW.AUS.OC PGP 2.3 
dave@esi.COM. AU ...munnari!esi.COM.AU! dave available 


End of Ham-Digital Digest V93 #59 
KKKKKKKKKKKKKKKKKKKKKK KERR KAKI 


